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1 

2 L Field of the Invention 
3 

4 This invention relates to managing information in a system of collaborative plan- 

5 ning. 
6 

7 2. Related Art 
8 

9 Storing accurate information and responding rapidly to user requests for that in- 

10 formation poses many problems in systems for supply chain management. These problems are 

1 1 compounded when (1) the entities in a supply chain are relatively far from the data, and (2) the 

1 2 data is stored in multiple places. 
13 

14 A first problem with information systems used in supply chain management is 

1 5 that inconsistencies in the data arise when multiple parties in a supply chain have write access to 

16 a database or when a master database is synchronized from smaller databases that are local to a 

1 7 customer. Under these circumstances, it is not possible for a party to receive accurate informa- 

1 8 tion about a transaction when at any one time the data about the transaction can be altered by one 

1 9 or more other parties. 
20 

21 A second problem involves the usability of the supply chain management system. 

22 Usability problems arise when data is stored large distances (measured in terms of network dis- 

23 tance or geographic distance) from the parties who use the data. Even with high-speed networks, 
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1 excessively long download and upload times create difficulties in receiving and sending infor- 

2 mation or successfully completing a transaction. One solution to usability problems involves 

3 distributing the information to locations that are closer to the user. However, this solution re- 

4 mains imperfect when the distributed information must be synchronized with one or more other 

5 databases associated with the supply chain management system or when the delay is attributable 

6 to processing the information. 
7 

8 Lastly, problems arise when one or more of the servers or databases in a distrib- 

9 uted system for supply chain management becomes unavailable. Under these circumstances, 

10 problems arise because a user cannot access the most recent version of data that is stored at the 

1 1 local database. 
12 

13 SUMMARY OF THE INVENTION 
14 

1 5 The invention provides a method and system for managing information in a multi- 

16 hub system for supply chain management and collaborative planning. A buyer, seller, negotia- 

17 tor, supplier or other entity (collectively known as trading partners) in a supply chain conducts 

18 business using one or more of the local electronic hubs that are remotely coupled to each other. 

19 Each local hub includes one or more servers, databases and computer applications that are dis- 

20 posed for receiving and sending messages, for caching data, and modifying information. Al- 

21 though these local hubs can be distributed throughout the world, they share a common set of dis- 

22 tributed data. The consistency of this data is safeguarded by controlling who has the authority to 

23 write to a portion of that data. A set of regional authorities are distributed among the local hubs 
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1 such that each regional authority protects different portions of the distributed data associated 

2 with the local hubs by controlling who may write to the portion of the data that is under the con- 

3 trol of the regional authority. 
4 

5 Regional authorities control access to data by identifying a local hub that owns 

6 that data. In this context, ownership of the data means that the owner has write access to the 

7 data. The authority to assign write access to the data rests with the regional authority. Regional 

8 authorities partition the set of all data maintained by the supply chain management system such 

9 that a regional authority has authority over a distinct subset of that data. Regional authorities 

10 coordinate with each other so that each particular regional authority can obtain instructions for 

1 1 data not belonging to that particular regional authority. 
12 

13 The number and location of regional authorities is established either (1) by the re- 

14 gional authorities themselves, in peer-to-peer cooperation, or (2) by a central authority in the 

15 supply chain system. In one embodiment, the number and location of regional authorities is in- 

16 tended to be optimized for both elements of local control (for example, distributed computing 

17 capability, failover capability, and lower communication latency) and for elements of clear coop- 

18 eration (for example, ease of identifying the appropriate regional authority, and simplicity of 

19 synchronization). Different factors can influence which local hub has regional authority over a 

20 particular portion of the data. These factors include: 
21 

22 • Physical region (for example, the regional authority for all of the local hubs in the 

23 eastern United States might be located in Boston); 
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1 • Class of goods (for example, there may be a regional authority for disk drives, an- 

2 other regional authority for memory chips, and so on); 

3 • Subnet locations (for example, a set of subnet locations may be assigned to a par- 

4 ticular regional authority); 

5 • Proximity (as measured by geography or network location) to a particularly valu- 

6 able client); and 

7 • Network location as measured by ping time (this is particularly useful, when try- 

8 ing to offer optimal download time to a valued client). 
9 

1 o In another aspect of the invention, messages that require processing are separated 



1 1 from messages that do not requiring processing. Messages that require processing are sent to a 

1 2 server (called a heavyweight server) where processing takes place. Messages that do not require 

13 processing are sent to a different server (called a lightweight server). By segregating traffic ac- 

14 cording to whether processing is required, clients that have simple requests can obtain the infor- 

1 5 mation they need quickly because the request is not slowed down while more complex requests 

1 6 are completed first. Some transactions can be separated into tasks that do not involve processing 

17 and tasks that do involve processing. Such transactions can be performed using both heavy- 

18 weight servers and lightweight servers. For example, if a supplier wishes to tell a buyer that a 

19 shipment will not be made as scheduled, the transfer of messages from the supplier to the buyer 

20 to that effect requires little processing and can be sent using a lightweight server. However, 

21 other aspects (such as updating a bill so that the buyer is not changed for the shipment, finding a 

22 new supplier, or identifying substitute goods or other actions) require further processing; these 

23 aspects of the transaction are handled using a heavyweight server. 
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1 Although the invention has general applicability to electronic commerce among 

2 multiple collaborators, buyers, suppliers, or designers in a supply chain or collaborative planning 

3 environments, it can be used in any transaction involving multiple parties. Moreover, techniques 

4 used by a preferred embodiment of the invention are also generally applicable to fields other than 

5 the specific applications disclosed herein. 
6 



7 BRIEF DESCRIPTION OF THE DRAWINGS 
8 

9 Figure 1 shows a block diagram of a high level view of a system of collaborative 

1 0 planning and supply chain management including a plurality of local hubs. 
11 

12 Figure 2 shows a series of messaging patterns for lightweight and heavyweight 

13 transactions in a system for collaborative planning and supply chain management. 
14 

15 Figure 3 shows a method of synchronizing information in a system of collabora- 

16 tive planning and supply chain management that includes a plurality of local hubs. 
17 

1 8 Figure 4 shows a method of using lightweight and heavyweight servers in a sys- 

1 9 tern for collaborative planning and supply change management. 



20 
21 
22 
23 
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1 Incorporated Disclosures 
2 

3 Inventions described herein can be used in conjunction with inventions described 

4 in the following applications: 
5 

6 • Application Serial No. 09/823,888, filed March 30, 2001, in the name of inventor Gregory 

7 Clark, titled "Private Collaborative Planning in a Many to Many Hub", attorney docket num- 

8 ber215.1001.01; 
9 

10 • Application Serial No. 1 0/087,444, filed March 1 , 2002, in the name of inventor Erik Stuart, 

11 titled "On-Line Auction with Different Rules Applicable to Different Phases", attorney 

12 docket number 2 15. 1011.01; 
13 

14 • Application Serial No. 09/967,905, filed September, 28, 2001 , in the name of inventor Greg- 

15 ory Clark, titled "Method for Business to Business Collaborative Viral Adoption", attorney 

16 docket number 215.1010.01; 
17 

1 8 • Application Serial No. 09/967,907, filed September 28, 2001 , in the name of inventor Greg- 

19 ory Clark, titled "Securing Information in a Design Collaboration and Trading Partner Envi- 

20 ronment", in the name of inventor Gregory Clark, attorney docket number 215.1 008.0 1 . 
21 

22 These applications are hereby incorporated by reference as if fully set forth 

23 herein. They are collectively referred to as the "incorporated disclosures." 
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I DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

2 

3 In the description herein, a preferred embodiment of the invention is described, 

4 including preferred process steps and data structures. Those skilled in the art would realize, after 

5 perusal of this application, that embodiments of the invention might be implemented using a va- 

6 riety of other techniques not specifically described, without undue experimentation or further 

7 invention, and that such other techniques would be within the scope and spirit of the invention. 
8 

9 Lexicography 
10 

I I The following terms relate or refer to aspects of the invention or its embodiments. 
12 The general meaning of each of these terms is intended to be illustrative and in no way limiting. 
13 

14 • Local hub - as used herein, the term "local hub" refers to a system for electronic supply 

15 chain management and collaborative design, including one or more web servers that is situ- 

16 ated in a location that is substantially proximate to a large number of trading partners. For 

1 7 example, a local hub may serve trading partners in a particular country (such as a local hub in 

1 8 Japan) or to serve partners in a particular business (such as a local hub situated in Armonk, 

1 9 New York that serves IBM). 
20 

21 • Regional authority - as used herein, the term "regional authority" refers to a local hub 

22 which has the authority to determine who may write to a database in a system for supply 

23 chain management or collaborative design. 
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1 • Heavyweight server - as used herein, the term "heavyweight server" refers to one or more 

2 servers at a local hub that are dedicated to responding to requests that require moderate or 

3 extensive processing. 
4 

5 • Lightweight server - as used herein, the term "lightweight server" refers to one or more 

6 servers at a local hub that are dedicated to responding to requests that require little or no 

7 processing. 
8 

9 • Ownership of the data - as used herein, the term "ownership of the data" refers to who has 

10 write access, who has authority to assign write access or who has a privacy interest in a par- 

1 1 ticular portion of a database associated with an electronic system of supply chain manage- 

1 2 ment or collaborative design. 
13 

14 • Trading partner - as used herein, the term "trading partner" refers to a buyer, seller, sup- 

1 5 plier, negotiator, or other party engaged in supply chain management or collaborative design. 
16 

17 System Elements 
18 

19 Figure 1 shows a block diagram of a system of supply chain management or col- 

20 laborative planning including a plurality of hubs. 
21 

22 A system 1 00 includes a plurality of local hubs 1 1 0, at least one client device 1 30 

23 under the control of a trading partner 131 and a communication network 140. These local hubs 
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1 1 10 are geographically distributed in various locations throughout the world where trading part- 

2 ners 131 are likely to be located. For example, the system 100 may include a first local hub 1 10 

3 in Tokyo, a second local hub 1 10 in Bangalore, and a third local hub 1 10 in London. Each local 

4 hub 1 10 can be coupled with other local hubs 1 10 so as to share information concerning supply 

5 chain management or collaborative design. At least one of the local hubs 1 10 is designated as a 

6 regional authority 120. 
7 

8 Each local hub 110 in the plurality of local hubs 110 includes one or more 

9 heavyweight servers 112, one or more lightweight servers 114, a database 116 and a software 

10 module 118. In some embodiments, the local hub 110 may include either a heavyweight server 

11 1 1 2 or a lightweight server 1 1 4 instead of both. 
12 

13 The heavyweight servers 112 include sufficient software to satisfy relatively 

14 complex requests from trading partners 131 and to process transactions between these trading 

15 partners 131. Examples of such transactions includes purchases and sales, modifications of ex- 

16 isting inventory, commitments and other transactions that require information to be written to the 

17 database 116 or require a moderate amount of processing. In the event that the heavyweight 

18 server 112 identifies a request that is substantially less complex, it forwards the request to the 

19 lightweight server 114. In this way, the heavyweight server 1 12 is reserved for more complex 

20 processing tasks. 
21 

22 A lightweight server 114 includes sufficient software to satisfy requests from 

23 trading partners 131 that do not require much processing. Examples of such requests include re- 
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1 quests to see what products or inventory are available, requests for confirmation of transactions 

2 that have already taken place, messages between trading partners as to the status of transaction 

3 and other requests for information that can be easily satisfied. In general, these transactions do 

4 not require writing to the database 1 16 or significant amounts of processing power. In the event 

5 that the lightweight server 1 14 identifies a request that is substantially more complex, the light- 

6 weight server 114 forwards the request to the heavyweight server 112. Since the lightweight 

7 server 114 does not provide complex processing, requests can be responded to quickly in real 

8 time or very close to real time. 
9 

10 In some embodiments, a local hub 1 10 includes either one or more lightweight 

1 1 servers 1 14 or one or more heavyweight servers 112. For example, lightweight servers 114 may 

12 be provided to some geographic locations and heavyweight servers 1 12 may be provided to other 

13 locations. Such embodiments decrease the latency for simple transactions and centralize the 

1 4 processing for more complex transactions. 
15 

16 The database 1 16 in each local hub 110 includes the same or substantially similar 

17 information. Each database 1 16 is periodically updated with respect to the other databases 1 16 

18 in a process known as synchronization. Each portion of each database 116 has an identifiable 

1 9 owner. The owner of a particular portion of a database 1 1 6 is usually a trading partner 1 3 1 at the 

20 local hub 110 who also has right to modify the data in that portion. For example, a disk drive 

21 supplier who stores information about available inventory in the database 116 is the owner of 

22 that information. Generally, parties who may exercise ownership rights are buyers and sellers. 

23 However, in other embodiments, ownership of data is determined in response to (1) who has a 
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1 right to the goods or money described by the information in the database 116, (2) who has a pri- 

2 vacy right with respect to the information, and (3) other parameters relating to a party's relation- 

3 ship to the information. 
4 

5 The software module 118 distinguishes between requests from trading partners 

6 131 that require moderate to extensive processing and those requests that require little to no 

7 processing. Requests that require moderate to extensive processing are directed to the heavy- 

8 weight server 112. Requests that require little to no processing are directed to the lightweight 

9 server 114. In some embodiments, the software module 1 18 is implemented as an interface cou- 

10 pling the heavyweight servers 112 and the lightweight servers 114. In other embodiments, the 

1 1 software module may reside on the client side. 
12 

13 In a preferred embodiment, control of the data in a local hub 1 10 is vested in a re- 

14 gional authority 120. The regional authority 120 has control of the data owned by the entities in 

15 a particular region of the world. The regional authority 120 preferably includes a local hub 1 10, 

16 but in other embodiments, may include a specialized device that is distinct in function from a 

17 local hub 1 10. Possession of a logical token 121 indicates what device (that is, which local hub 

18 1 10) is the regional authority 120 at that time. 
19 

20 The regional authority 120 maintains data consistency by controlling who may 

21 write to the data in at least one database 116 (or portion of a database 1 16), and by controlling 

22 who may perform any other activity that changes the state of the information in the database 1 16. 
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1 Since the regional authority 120 does not allow multiple parties to write to the same information 

2 at the same time, the information among all the local hubs 1 1 0 is consistent. 

3 A local hub 1 10 is designated as a regional authority 120 in response to a number 

4 of different factors, including 



5 

6 • Physical region (for example, the regional authority for all of the local hubs in the 

7 eastern United States might be located in Boston); 

8 • Class of goods (for example, there may be a regional authority for disk drives, an- 

9 other regional authority for memory chips, and so on); 

I o • Subnet locations (for example, a set of subnet locations may be assigned to a par- 

I I ticular regional authority); 

\2 • Proximity (as measured by geography or network location) to a particularly valu- 

13 able client); and 

14 • Network location as measured by ping time (this is particularly useful, when try- 

1 5 ing to offer optimal download time to a valued client). 
16 

17 In one embodiment, the number and location of regional authorities is intended to 



18 be optimized for both elements of local control (for example, distributed computing capability, 

1 9 failover capability, and lower communication latency) and for elements of clear cooperation (for 

20 example, ease of identifying the appropriate regional authority, and simplicity of synchroniza- 

21 tion). In such embodiments, a regional authority 120 can transfer it's authority to another local 

22 hub 1 10 (for example, if business conditions change) by transferring the logical token 121. This 

23 token 121 is exchanged between an outgoing regional authority 120 and an incoming regional 
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1 authority 120. This token 121 may include a set of computer program code, a set of access 

2 privileges, or other similar indicator of authority. 

3 The plurality of local hubs 110 can also implement a failover configuration 

4 among the local hubs 1 10. For example, if a local hub 1 10 in Los Angeles fails because of a lo- 

5 cal disaster (or due to overuse, or any other reason), trading partners 131 can be transparently 

6 redirected to a different local hub 1 10 in San Francisco. Redirection might be performed by a 

7 software element in a client device 1 30 under the control of a trading partner 1 3 1 , by a software 

8 element in a redirecting router associated with the local hub 1 1 0, or otherwise. Thus, there is no 

9 break in service or loss of data, due to synchronization to reflect activity at the local hubs 110. 
10 

11 The client devices 130 may include a personal computer, a laptop, a hand-held 

12 computer (such as a personal digital assistant), a set of multiple computing devices operating in 

1 3 concert or cooperation, a portion of a computing device used for a particular function (such as a 

14 software package used on a server), or some combination or mixture thereof, or any other device 

1 5 fitting within the general Turing paradigm. The trading partners 1 3 1 include one or more of the 

16 following: buyers, sellers, collaborators, entities in a supply chain, senders of information, re- 

1 7 cipients of information and other users of a system 1 00. In one embodiment, the trading partners 

18 131 include companies involved in electronics and computers. 
19 

20 The client devices 130 may access the local hubs 1 10 through (1) an element in- 

21 eluded in a browser on the client side, (2) a computer program stored on the client side that re- 

22 quires processing to be performed at the local hub 1 1 0 (for example, a thin client) or a enterprise 

23 link where dedicated bandwidth is provided between the client device 1 30 and the local hub 1 1 0. 
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1 The communication network 140 is disposed for communicating data between (1) 

2 client devices 1 30 and the local hubs 1 1 0, and (2) between the different local hubs 110. In a pre- 

3 ferred embodiment, the communication network 140 includes a packet switched network such as 

4 the Internet, as well as (in conjunction with or instead of) an intranet, an enterprise network, an 

5 extranet, a virtual private network, a virtual switched network, or in one preferred embodiment in 

6 conjunction with a set of dedicated communication links. In alternative embodiments, the com- 

7 munication network 140 may include any other set of communication links that couple the local 

8 hubs 1 10 with each other and with client devices 130. In some embodiments, dedicated band- 

9 width can be used to couple the local hubs with each other. In other embodiments, dedicated 

10 bandwidth can be used to couple client device 130 under the control of a valued trading partner 

11 131 with the local hub 110. In this way, different classes of service can be provided to different 

1 2 trading partners 131. 
13 

14 Figure 2 shows a series of messaging patterns for lightweight and heavyweight 

1 5 transactions in a system for collaborative planning and supply chain management. 
16 

17 Figure 2 A shows a messaging pattern for a transaction involving a lightweight 

18 server 1 14. Although the transaction described herein involves a message from a supplier to a 

19 buyer that a scheduled shipment will not arrive, this messaging pattern is applicable for any 

20 transaction or part of a transaction that does not involve moderate or extensive processing at the 

21 local hub 110. 
22 



Express Mailing EL 768 962 227 US 



15 



215.1021.02 



1 In data flow 201, a message is sent from a first trading partner 131 (in this exam- 

2 pie, a supplier) to the lightweight server 1 14 indicating that a scheduled shipment will not arrive. 
3 

4 In a data flow 202, the message regarding the shipment is sent from the light- 

5 weight server 1 14 to the second trading partner 13 1 (in this case a buyer), n those embodiments 

6 in which software module 118 resides on the client side, the acknowledgment may be sent di- 

7 rectly from the first trading partner 1 3 1 to the second trading partner 131. 



8 

9 In a data flow 203, the second trading partner 131 receives and processes the in- 

1 0 formation. For example, the second trading partner 1 3 1 may notify the receiving department that 

1 1 the shipment will not arrive. 
12 

13 In a data flow 204, the second trading partner 131 sends a message to the light- 

14 weight server 114. In this example, this may include an acknowledgment that the message was 

15 received. 
16 

17 In a data flow 205, the lightweight server 114 relays the acknowledgment from 

18 the second trading partner 131 to the first trading partner 131. In those embodiments in which 

19 software module 118 resides on the client side, the acknowledgment may be sent directly from 

20 the second trading partner 1 3 1 to the first trading partner 1 3 1 
21 

22 In a data flow 206, the first trading partner 1 3 1 processes the acknowledgment. 

23 
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1 Figure 2B shows a messaging pattern for a transaction involving a heavyweight 

2 server 112. Although the transaction described herein involves a message from a supplier to a 

3 buyer that a scheduled shipment will not arrive, this messaging pattern is applicable for any 

4 transaction, or part of a transaction that involves moderate or extensive processing at the local 

5 hub 110. 
6 



7 In a data flow 207, a first trading partner 131 (in this example, a supplier) sends a 

8 message to the local hub 1 10 that a shipment to a second trading partner 131 (in this example, a 

9 buyer) will not be available as scheduled. 
10 

11 In a data flow 208, heavyweight server 1 12 at the local hub 110 receives the mes- 

1 2 sage and processes it. This processing may include: 
13 

14 • Identifying substitute suppliers; 

1 5 • Identifying substitute goods; 

1 6 • Identifying a list of negotiating partners; 

17 • Other steps such as may be necessary to mitigate damages due to the missing 

18 shipment 
19 

20 In a data flow 209, the heavyweight server 1 12 relays a message concerning the 

2 1 results of this processing to the second trading partner 131. These results might include: 
22 

23 • A list of substitute suppliers 
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1 • A list of substitute goods; 

2 • Information about a negotiation for new goods; 

3 • Other information relating to the cancelled shipment. 
4 

5 In a data flow 210, the second trading partner 131 receives this information and 



6 processes it. Processing the information may include deciding among the suppliers, substitute 

7 goods, determining if a negotiation is satisfactory, modifying production schedules to reflect the 

8 lack of anticipated goods and other actions to compensate for the lack of goods. 
9 

10 In a data flow 2 1 1 , the second data partner 1 3 1 sends a result of this processing to 

1 1 the heavyweight server 1 12. The result of the processing might include a list of parties to be in- 

12 eluded in a negotiation for replacement goods, an acceptable price range for substitute goods, a 

1 3 deadline for a substitute shipment or other information. 
14 

15 In a data flow 212, the heavyweight server 1 12 receives the information from the 

16 second data partner 131 and processes it. Processing might include setting up negotiating dates, 

1 7 identifying other trading partners that have available inventory within the acceptable price range 

18 or by the stated deadline. 
19 

20 In a data flow 213, the heavy weight server 1 12 sends a message to one or more 

2 1 suppliers that may be involved in subsequent transactions to replace the missing goods. 
22 

23 
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1 Method of Operation 
2 

3 A method 300 includes a set of flow points and process steps as described herein. 
4 

5 In one embodiment, the method 300 is performed by the system 100. In 

6 other embodiments, the method 300 may be performed by other systems. Although the 

7 method 300 is described serially, the steps of the method 300 can be performed by separate ele- 

8 ments in conjunction or parallel, whether asynchronously, in a pipelined manner, or otherwise. 

9 There is no particular requirement that the method 300 be performed in the same order in which 
1 0 this description lists the steps, except where so indicated. 

11 

12 At a flow point 310, the system 100 is ready to begin performing a method 300. 

13 At the outset, a first local hub 1 10 is designated as the regional authority 120 for a plurality of 

14 other local hubs 110. The regional authority 120 possesses a token 121. The token 121 allows 

1 5 the regional authority 1 20 to control who may write to a database 1 1 6. 
16 

17 At a step 3 1 5, a pattern of activity within the system 1 00 changes so it is desirable 

18 to designate a different local hub 1 10 as regional authority 120. This shift may correspond to a 

1 9 change business activity or a failure at a local hub. It may also be desirable to designate a differ- 

20 ent local hub 1 10 as regional authority 120 in response to the desires of a valued customer or 

2 1 some other variable. As a result of these changes, a different local hub 1 1 0 is identified. 
22 
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1 At a step 320, a token 121 is sent from the regional authority 120 to the local hub 

2 110 identified in step 315. The local hub 110 that receives the token becomes the new regional 

3 authority 120. The former regional authority 120 no longer has the authority to synchronize data 

4 among the other local hubs 1 1 0, and becomes an ordinary local hub 1 10. 
5 

6 At a flow point 325, the new regional authority 120 is ready to synchronize data 

7 on behalf of the system 1 00. Steps 3 1 5 and 320 are repeated whenever there is a significant shift 

8 in business activity or in any other parameter such as may be used to identify the regional 

9 authority 120. 
10 



1 1 Figure 4 shows a method of using lightweight and heavyweight servers in a sys- 

1 2 tern for collaborative planning and supply change management. 
13 

14 In one embodiment, the method 400 is performed by the system 100. In other 

15 embodiments, the method 400 may be performed by other systems. Although the method 400 is 

16 described serially, the steps of the method 400 can be performed by separate elements in con- 

17 junction or parallel, whether asynchronously, in a pipelined manner, or otherwise. There is no 

18 particular requirement that the method 400 be performed in the same order in which this de- 

1 9 scription lists the steps, except where so indicated. 



20 

21 In a flow point 410, a first trading partner 131 wishes to conduct business at a lo- 

22 cal hub 1 10. This transaction may involve selling or buying goods (for example, disk drives, or 

23 other computer parts), conducting an auction, making a request for quote, conducting a negotia- 
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1 tion, communicating with a second trading partner 131 about an transaction that is already is 

2 process or some other type of business that can be performed at the local hub 1 10. The first 

3 trading partner 131 uses a client device 130 to contact the local hub 110 and sends a message re- 

4 garding the desired transaction. 
5 

6 In a step 415, the local hub 110 receives the message. Software module 118 

7 parses the message and identifies tasks that should be performed by a lightweight server 1 14 and 

8 tasks that should be performed by a heavyweight server 1 12. The software module 118 gener- 

9 ates lists of these tasks and sends the list to the appropriate server. Tasks that require little or no 

10 processing are sent to the lightweight server 1 14. Tasks that require moderate or extensive proc- 

11 essing are sent to the heavyweight server 112. In some embodiments, the heavyweight server 

12 112 and lightweight server 114 reside at the same local hub 110. In other embodiments, the 

1 3 heavyweight server 1 1 2 and lightweight server reside at different local hubs. 
14 

15 In a step 420, the lightweight server 1 14 receives the task list from the software 

1 6 module 1 1 8 and redirects the message to the intended trading partner 131. 
17 

18 In a step 425, the heavyweight server 112 receives the task list from the software 

19 module 118 and processes it. This processing may involve storing information in database 1 16, 

20 calculating information to send to the intended trading partner 131, calculating information to 

21 send to other prospective trading partners 131 or providing the first trading partner 131 with 

22 processed information or other activities that require computer processing. In one embodiment, 
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1 steps 420 and 425 occur approximately simultaneously. However, since step 420 requires little 

2 or no processing, it is usually completed before step 425. 
3 

4 In a step 430, the heavyweight server 1 12 sends a result associated with the proc- 

5 essing to the first trading partner 1 3 1 or a different trading partner 131. 
6 

7 Additional messages may be sent between the heavyweight server 1 12, the light- 

8 weight server 1 14, and one or more trading partners 131. Each additional message involves per- 

9 forming step 1 1 5 so as to parse the message and determine whether tasks associated with the 

10 message should be sent, in whole or in part to the heavyweight server 112, the lightweight server 

11 1 14 or both. Steps 420 through 430 are performed as appropriate until the transaction is com- 

12 plete. 
13 

1 4 Alternative Embodiments 
15 

16 Although preferred embodiments are disclosed herein, many variations are possi- 

17 ble which remain within the concept, scope and spirit of the invention; these variations would be 

1 8 clear to those skilled in the art after perusal of this application. 
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